1. The Field of the Invention
The present invention relates to systems and methods for allowing multiple drivers in an I/O system to participate in processing an I/O request. More specifically, the present invention allows one driver to interrupt the normal sequence of processing an I/O request in order to pass control to another driver for further processing of the I/O request.
2. The Prior State of the Art
A functional computer system generally consists of three fundamental components. The first component is the computer hardware. The computer hardware includes such devices as a central processing unit (CPU), system memory such as RAM or ROM, mass storage such as magnetic or optical disk storage, a keyboard or other input device, and a display or other output device. Users of computer systems generally interact with user or application programs. Such programs include the familiar word processing applications, spread sheet applications, database applications, and so forth. The final component of a modern, functional computer system is an operating system. The computer operating system performs many functions such as allowing a user to initiate execution of an application program. In addition, modern operating systems also provide an interface between an application program and the computer system hardware. Thus, while it was once commonplace for an application program to directly access computer system hardware, modern operating systems provide standardized, consistent interfaces that allow user applications to interface with or access computer hardware in a standardized manner.
In order to provide a consistent interface between a process such as a user application and a particular type of hardware device, there may be several software layers between the actual hardware and the process. For example, a process may make a call into the operating system. The operating system, in turn, may utilize the services provided by a hardware driver layer. The hardware driver layer would then interface directly with the hardware. A primary advantage of such a layered approach is that layers may be added or replaced without creating a huge impact on the remaining layers. For example, if a new hardware device is added to a system, a new driver may be added, which allows the operating system to access the hardware. All these changes may take place with minimal or no impact on existing application processes.
When drivers are used to interface with hardware devices, the trend has traditionally been to create monolithic drivers, which incorporate all functionality needed to interface an operating system with a particular hardware device. More recently, operating systems have been developed that use multiple drivers to perform various I/O tasks. Examples of this are particularly prevalent when dealing with I/O requests to disk or other mass storage.
Data is typically stored on mass storage devices in a hierarchical fashion with directories and files organized in a hierarchy resembling a tree structure. The location of any file or directory is typically specified by a file path name. The path name typically begins with a root or starting directory and names each subdirectory until the desired file or directory is reached. For example, a file called "file.dat" may be stored in directory "temp", which is a subdirectory of the root directory "root". Thus, the path name would be /root/temp/file.dat. Resolving file names in a file system is typically a multistage procedure. It generally begins with stage that decodes all of the named components that needs to be successfully identified by the file system. The procedure then continues with an iterative process of identifying, usually from left to right, the successive components in the file name. The procedure finishes with the success or failure of each of these name resolutions. Thus, in the example above, the path name would be broken down into successive components and the resolution process would identify, in turn, the root directory, the temp subdirectory, and the file file.dat.
Most UNIX systems allow several data managers to co-exist within one installation. To achieve this, the hierarchical file name space is partitioned into sub-trees of file and directory names. A dedicated data manager then administers each sub-tree. When an I/O request is made, the name resolution process resolves the name to a particular sub-tree and the I/O request may be handled by the data manager for that sub-tree. The data manager may then call the built-in UNIX file system in order to perform the actual storage and retrieval of data. Thus, the data managers act as a value added component extending the capabilities of a particular file system.
When multiple data managers exist in a UNIX I/O system, routing of the request to the proper data manager is achieved through the mechanism of "mount points." One mount point is established in the name space to represent each of the sub-trees. During the name resolution process, when a mount point is encountered, the UNIX I/O system directs the request to the appropriate data manager in charge of administering the sub-tree represented by the mount point. The appropriate data manager then continues with the name resolution process.
The standard UNIX file system also supports symbolic links. Symbolic links represents a built-in case in which the procedure for resolving a name is begun afresh using a second name. When a symbolic link is encountered, one file name is blindly substituted for another and the name resolution process is begun anew with the substituted name.
Prior art systems have thus utilized multiple data managers to manage different parts of the address space. These data managers also were able to interact with the standard file system in order to process an I/O request. The model used in prior art systems, however, was relatively deterministic and could not be extended to cover scenarios not envisioned by its designers. In other words, the interaction between a data manager and the file system is relatively fixed with each performing a defined role. Removing either the data manager or the file system and replacing them with another component to perform some other function would be difficult. Similarly, attempting to place another manager in the system to perform a function other than managing a sub-tree would also be difficult, if not impossible, using existing driver models. It would, therefore, be desirable to provide a method that allows multiple components to work together to process an I/O request where the number of components is not fixed and may be extended or modified arbitrarily to add new components handling functions not envisioned when the system was established. It would also be desirable to allow replacement of any component without causing major disruption to the remaining components.
Another problem with the prior art is that although multiple data managers are used, their participation in the name resolution process is limited to the name space over which they have control. In other words, if multiple mount points are to be identified, multiple data managers must be installed, each to handle a particular mount point. It would be desirable to allow a single data manager to manage multiple mount points or sub-trees of information.
Thus, what is needed is a mechanism to dynamically extend and reconfigure an I/O system that uses a plurality of data managers or drivers to process I/O requests. It would also be desirable to allow such reconfiguration an extension with minimal impact on the other data managers or drivers within the system.